[Previous] [Next] [Index]
[Thread]
Re: GSS API (as a DLL)...
>> System security things should be statically linked. Especially on
>> Suns, with their LD_PRELOAD functionality. The load library path
>> remains a vulnerability.
No it doesn't. If the program runs as the user, then if I can spoof
your libraries, I can just as easily spoof ls as a "system security
thing".
If the program is setuid, then the dynamic loader should ignore
LD_LIBRARY_PATH if euid != ruid. This is what SunOS (at least the
newer versions) does.
>> Of course you could counter with 'I am only going to allow the
>> authentication methods listed in this file', but then there is no
>> advantage in dynamic linking over runtime linking, and very little
>> over static linking.
This is *exactly* what I would say. The advantages over static linking
are clear: you don't have to do it when you get a new security
mechanism. Dynamic linking also requires you recompile if you want to
add new mechanisms, as the dynamic linking systems I'm familiar with
assume one symbol space; if you have two libraries with the same
function names, you can't use both at the same time.
Now that I've said that, I'll be a hypocrite. This is www-security,
not random-os-security. There are other lists for that.
Marc
Follow-Ups: